Related: #177

I think that entire commit should be reverted instead. This package is an ES module so it should not declare a namespace.

@smrq would this commit actually fix this? I wouldn't mind just merging it in rather than having to go through a commit reversal.

After doing some more investigation, I think the situation is as follows.

The state of the typings prior to the referenced commit was valid for es/ng-redux.js (ESNext), but invalid for lib/ng-redux.js (CJS) and dist/ng-redux.js (UMD).

The state after the referenced commit is valid for CJS and UMD but invalid for ESNext. Thus, that commit breaks Webpack builds (which use the ESNext version).

After this patch, I think it is valid for UMD and ESNext, but invalid for CJS.

There's some additional complication in that the current state is extra-permissive: it allows you to compile TypeScript code using e.g. the UMD syntax in an environment where you are not using the UMD version of the code, which will result in runtime rather than compile-time errors.

A single typings file can never be valid for both the CJS and ESNext builds, as far as I can tell. The two module exports are mutually exclusive. The UMD build can be supported by adding the namespace and exporting that, but that erroneously makes the UMD syntax compile when using the other builds.

I'm not actually sure what the best course of action is. I'm trying to find an example of another project with multiple mutually-incompatible TypeScript typings.

@smrq looking at Redux's own declaration, it doesn't use the namespace idea. It actually just exports interfaces to all the individual methods that you can get from redux. Maybe we can just lose the namespace?

You're right. Well, if it's good enough for Redux, it should be good enough here.

That said, the export should still be an ES6 default export here, since that's how the code is written. (Redux itself doesn't have a default ES6 export.)